﻿<h1>Value Parts</h1>

<p>
The articles following the current one will introduce more kinds of Go types.
To easily and deeply understand those articles,
it is best to read the following content in the current article firstly
before reading those articles.
</p>

<h3>Two Categories of Go Types</h3>

<div>
<p>
Go can be viewed as a C-family language, which can be confirmed from
the two previous articles <a href="pointer.html">pointers in Go</a>
and <a href="struct.html">structs in Go</a>.
Struct types and pointer types in Go and C are much alike.
</p>

<p>
On the other hand, Go can be also viewed as a C language framework.
This is mainly reflected from the fact that Go supports several kinds of types
whose value memory structures are not totally transparent, whereas
the main characteristic of C types is the memory structures of C values are transparent.
Each C value in memory occupies one continuous memory segment.
However, values of some kinds of Go types may often consist of more than one continuous memory segments.
</p>

<p>
Each continuous memory segment hosts a value, more speaking precisely, a value part.
The following picture depicts a multi-part value.
Its direct part is referencing its indirect underlying part.

<div class="text-center">
<img src="res/value-parts.png" alt="value part"></img>
</div>
</p>

<p>
The following two paragraphs describe two categories of Go types.
</p>

<p>
The kinds of types in the first category are all C alike.
These types include boolean types, numeric types, struct types, pointer types,
array types and unsafe pointer types.
Array types will be explained in the next article
and unsafe pointer types will be explained in the article
<a href="unsafe.html">type-unsafe pointers</a> later.
Each C alike value only consists of one direct transparent value part.
</p>

Other kinds of types belong to the second category.
Values of types in the category may contain underlying parts,
and their direct parts are not transparent.
Specifically speaking, these kinds of types include
<ul>
<li>slice types</li>
<li>map types</li>
<li>channel types</li>
<li>function types</li>
<li>interface types</li>
<li>string types</li>
</ul>

<p>
The kinds of types in the second category bring much convenience to Go programming
by encapsulating many implementation details.
Different Go compilers may adopt different internal implementations
for these types, but the external behaviors of values of these types
must satisfy the requirements specified in Go specification.
</p>

<p>
These types will be explained detailedly in the following articles.
</p>

Note,
<ul>
<li>
	whether or not interface and string values may contain underlying parts
	is compiler dependent. For the standard Go compiler implementation,
	interface and string values may contain underlying parts.
</li>
<li>
	whether or not functions values may contain underlying parts
	is hardly, even impossible, to prove.
	In Go 101, we will view functions values may contain underlying parts.
</li>
</ul>

<p>
The types in the second category are not very fundamental types for a language,
we can implement them from scratch by using the types from the first category.
However, by encapsulating some common or unique functionalities and
supporting these types as the first-class citizens in Go,
the experiences of Go programming become enjoyable and productive.
</p>

<p>
On the other hand, these encapsulations adopted in implementing the types
in the second category hide many internal definitions of these types.
This prevents Go programmers from viewing the whole pictures of these types,
and sometimes makes some obstacles to understanding Go better.
</p>

<p>
To help gophers better understand the types in the second category
and their values, the following content of this article will introduce
the internal structure definitions of these kinds of types.
The detailed implementations of these types will not be explained here.
The explanations in this article are based on, but not exactly the same as,
the implementations used by the standard Go compiler.
</p>
</div>

<h3>Two Kinds of Pointer Types in Go</h3>

<div>
<p>
Before showing the internal structure definitions of the kinds of types
in the second category, let's clarify more on pointers and references.
</p>

<p>
We have learned <a href="pointer.html">Go pointers</a> in the article before the last.
The pointer types in that article are type-safe pointer types.
In fact, Go also supports type-unsafe pointer types.
The <code>unsafe.Pointer</code> type provided in the <code>unsafe</code>
standard package is like <code>void*</code> in C language.
Types whose underlying types are <code>unsafe.Pointer</code>
are called unsafe pointer types in Go 101.
</p>

<p>
In most other articles in Go 101, if not specially specified,
when a pointer type is mentioned, it means a type-safe pointer type.
However, in the following parts of the current article,
when a pointer type is mentioned,
it may be either a type-safe pointer type or a type-unsafe pointer type.
</p>

A pointer value stores a memory address of another value,
unless the pointer value is a nil pointer.
We can say the pointer value references the other value,
or the other value is referenced by the pointer value.
Values can also be referenced indirectly.
<ul>
<li>
	If a struct value <code>a</code> has a pointer field <code>b</code>
	which references a value <code>c</code>, then we can say the struct
	value <code>a</code> also references value <code>c</code>.
</li>
<li>
	If a value <code>x</code> references (either directly or indirectly)
	a value <code>y</code>, and the value <code>y</code> references
	(either directly or indirectly) a value <code>z</code>,
	then we can also say the value <code>x</code> (indirectly)
	references value <code>z</code>.
</li>
</ul>

<p>
Below, we call a struct type with fields of pointer types as a <b>pointer wrapper type</b>,
and call a type whose values may contains (either directly or indirectly) pointers a <b>pointer holder type</b>.
Pointer types and pointer wrapper types are all pointer holder types.
Array types with  pointer holder element types are also pointer holder types.
(Array types will be explained in the next article.)
</p>
</div>

<h3>(Possible) Internal Definitions of the Types in the Second Category</h3>

<p>
The possible internal definitions of the types in the second category are shown below.
</p>

<h4>Internal definitions of map, channel and function types</h4>

<!--
https://groups.google.com/forum/#!topic/golang-nuts/91phVZwiDf8
-->

<div>
The internal definitions of map, channel and function types are similar:
<pre class="line-numbers"><code class="language-go">// map types
type _map *hashtableImpl

// channel types
type _channel *channelImpl

// function types
type _function *functionImpl
</code></pre>

<p>
So, internally, types of the three kinds are just pointer types.
In other words, the direct parts of values of these types are pointers internally.
For each non-zero value of these types,
its direct part (a pointer) references its indirect underlying implementation part.
</p>

<p>
BTW, the standard Go compiler uses hashtables to implement maps.
</p>

</div>

<h4>Internal definition of slice types</h4>

<div>
The internal definition of slice types is like:
<pre class="line-numbers"><code class="language-go">type _slice struct {
	// referencing underlying elements
	elements unsafe.Pointer
	// number of elements and capacity
	len, cap int
}
</code></pre>

<p>
So, internally, slice types are pointer wrapper struct types.
Each non-zero slice value has an indirect underlying part
which stores the element values of the slice value.
The <code>elements</code> field of the direct part references
the indirect underlying part of the slice value.
</p>
</div>

<h4>Internal definition of string types</h4>

<div>
Below is the internal definition for string types:
<pre class="line-numbers"><code class="language-go">type _string struct {
	elements *byte // referencing underlying bytes
	len      int   // number of bytes
}
</code></pre>
<p>
So string types are also pointer wrapper struct types internally.
Each string value has an indirect underlying part storing
the bytes of the string value, the indirect part is referenced
by the <code>elements</code> field of that string value.
</p>
</div>

<a class="anchor" id="interface-structure"></a>
<h4>Internal definition of interface types</h4>

<div>
Below is the internal definition for general interface types:
<pre class="line-numbers"><code class="language-go">type _interface struct {
	dynamicType  *_type         // the dynamic type
	dynamicValue unsafe.Pointer // the dynamic value
}
</code></pre>

<p>
Internally, interface types are also pointer wrapper struct types.
The internal definition of an interface type has two pointer fields.
Each non-zero interface value has two indirect underlying parts
which store the dynamic type and dynamic value of that interface value.
The two indirect parts are referenced by the <code>dynamicType</code>
and <code>dynamicValue</code> fields of that interface value.
</p>

In fact, for the standard Go compiler, the above definition is only used
for blank interface types.
Blank interface types are the interface types which don't specify any methods.
We can learn more about interfaces in the article
<a href="interface.html">interfaces in Go</a> later.
For non-blank interface types, the definition like the following one is used.

<pre class="line-numbers"><code class="language-go">type _interface struct {
	dynamicTypeInfo *struct {
		dynamicType *_type       // the dynamic type
		methods     []*_function // method table
	}
	dynamicValue unsafe.Pointer // the dynamic value
}
</code></pre>

<p>
The <code>methods</code> field of the <code>dynamicTypeInfo</code> field
of an interface value stores the implemented methods of the dynamic type
of the interface value for the (interface) type of the interface value.
</p>

<!--
<p>
Go runtime will create at most one dynamic type information struct for
each interface type and dynamic type pair
and store the struct value in the global zone.
For the standard Go runtime, a dynamic type information struct value
will be never garbaged collected once it is created.
All <code>_type</code> values are also stored in the global zone.
In other words, the <code>_type</code> values and dynamic type information
struct values are shared by many interface values,
they don't belong to any specified interface value.
For this reason, the current article will view each interface value may
has at most one underlying value,
which is referenced by the <code>dynamicValue</code> field.
</p>
-->

</div>

<a class="anchor" id="about-value-copy"></a>
<h3>Underlying Value Parts Are Not Copied in Value Assignments</h3>

<p>
Now we have learned that the internal definitions of the types
in the second category are either pointer types or struct types.
Certainly, Go compilers will never view values of the types in the second category
as pointers or structs in user programs.
These definitions are just used internally in implementing Go runtimes.
</p>

<p>
In Go, each value assignment (including parameter passing, etc) is
a shallow value copy if the involved destination and source values
have the same type (if their types are different, we can think that
the source value will be implicitly converted to the destination type
before doing that assignment).
In other words, only the direct part of the source value is copied
to the destination value in an value assignment.
If the source value has underlying value part(s),
then the direct parts of the destination and source values
will reference the same underlying value part(s),
in other words, the destination and source values will
share the same underlying value part(s).

<div class="text-center">
<img src="res/value-parts-copy.png" alt="value part copying"></img>
</div>

</p>

<p>
In fact, the above descriptions are not 100% correct in theory, for strings and interfaces.
The <a href="https://golang.org/doc/faq#pass_by_value">official Go FAQ</a> says
the underlying dynamic value part of an interface value should be copied
as well when the interface value is copied.
However, as the dynamic value of an interface value is read only,
the standard Go compiler/runtime doesn't copy the underlying
dynamic value parts in copying interface values.
This can be viewed as a compiler optimization.
The same situation is for string values and the same optimization
(made by the standard Go compiler/runtime) is made for copying string values.
So, for the standard Go compiler/runtime, the descriptions in the last section
are 100% correct, for values of any type.
</p>

<p>
Since an indirect underlying part may not belong to any value exclusively,
it doesn't contribute to the size returned by the <code>unsafe.Sizeof</code> function.
</p>

<!--
<p>
As above mentioned, Go map values are hashtables internally.
When an interface or a string value is used as a map key, its underlying part(s)
are counted in calculating its hash.
When a channel is used as a map key, its underlying part(s) are not counted
in calculating its hash.
Slice, map and function values can't be used as map keys.
</p>
-->

<a class="anchor" id="more=about-reference"></a>
<h3>About the "Reference Type" and "Reference Value" Terminologies</h3>

<div>
The word <b><i>reference</i></b> in Go world is a big mess.
It brings many confusions to Go community.
Some articles, including some <a href="https://golang.org/doc/faq#references">official ones</a>,
use <b><i>reference</i></b> as qualifiers of types and values,
or treat <b><i>reference</i></b> as the opposite of <b><i>value</i></b>.
This is strongly discouraged in Go 101.
I really don't want to dispute on this point.
Here I just list some absolutely misuses of <b><i>reference</i></b>:
<ul>
<li>
	only slice, map, channel and function types are reference types in Go.
	(If we do need the <b><i>reference type</i></b> terminology in Go,
	then we shouldn't exclude any pointer holder types from reference types).
</li>
<li>
	references are opposites of values.
	(If we do need the <b><i>reference value</i></b> terminology in Go,
	then please view reference values as special values, instead of
	opposites of values.)
</li>
<li>
	some parameters are passed by reference.
	(Sorry, all parameters are passed by copy in Go.)
</li>
</ul>

<p>
I don't mean the <b><i>reference type</i></b> or <b><i>reference value</i></b>
terminologies are totally useless for Go,
I just think they are not very essential, and they bring many confusions in using Go.
If we do need these terminologies, I prefer to define them as pointer holders.
And, my personal opinion is it is best to limit the <b><i>reference</i></b>
word to only representing relations between values by using it as a verb or a noun, and never use it as an adjective.
This will avoid many confusions in leaning, teaching and using Go.
</p>
</div>

